home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 4⁄27⁄90 / 1173-RE[∞]- More on exter-Apr90 next >
Encoding:
Text File  |  1990-04-23  |  4.1 KB  |  89 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    4339690                         21-April-90        05:37PDT
  4.  
  5. From:   POWERUP.ENG                     Power Up Software,PRT
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    RE[∞]- More on external c
  10.  
  11. Attn:   MacApp.Tech$
  12. SentBy: James Plamondon
  13. Date   4/20/90
  14. Subject    RE[∞]- More on external cod
  15. From   James Plamondon
  16. To Kemink, Joost
  17. CC   MacApp.Tech$
  18.  
  19. Subject:   RE[∞]: More on external code
  20. Dear Joost, et al.,
  21.  
  22. I am slowly digesting your excellent and informative link on CUST resources in
  23. Xenon.  Please allow me to follow up with a few questions and comments (in no
  24. particular order).
  25.  
  26. You mention a problem with CUST resource ID clashes, and the potential for
  27. problems with resource name clashes.  If one assumes that your 'package'
  28. approach is followed, in which each CUST resource and any support resources it
  29. requires are all in a single file, with only one CUST resource per file, then
  30. one might be able to use the file's ioRefNum to uniquely identify the CUST
  31. package.  Would this work?
  32.  
  33. I'm intrested in knowing some of the nitty-gritty details of your
  34. implementation, if I may.  What kind of header (if any) do your CUST resources
  35. have?  When are they locked down?  Are your CUST resources' main routines
  36. re-entrant?  Do they need to be?  Do they have any global (or pseudo-global)
  37. data associated with them?  Are they passed an identical parameter block for
  38. each selector, or does the parameter block vary from selector to selector?
  39. What are the arguments to the CUST resource's main routine?  Does the CUST
  40. resource request services by calling a single global routine with a service
  41. selector, or by jumping through a table of service routine pointers?  If the
  42. latter, is a library of glue provided to make the use of this table more
  43. convenient (e.g., glue like that used when calling PACK resource routines)?
  44.  
  45. As to callbacks — it is certainly true that the applications using CUST
  46. resources will vary in their needs. Certainly application-specific callbacks
  47. will vary from application to application.
  48.  
  49. However, it may also be true that all CUST resources will make similar demands
  50. on MacApp itself.  A suite of standard MacApp callbacks could be implemented
  51. as part of the TCust class.  The callbacks would certainly include a set of
  52. support services specific to external code resources, such as asking MacApp to
  53. creating a view, a menu, a menu item, enable or disable views and/or menu
  54. items, etc. — all the user interface goodies that a TCust object could do
  55. directly, but which a code resource would have to do indirectly.
  56.  
  57. Thus, any descendant of TCust would have access to all of the MacApp's CUST
  58. callback services.  An application would subclass TCust in oder to add its own
  59. application-specific callback services, and to add methods to TCust that would
  60. pass messages through to the CUST resource.
  61.  
  62. The TCust class would also handle the details of keeping the CUST in memory
  63. when necessary (possibly as defined by a suite of bits in the CUST resource's
  64. header, as with the DRVR resource's dNeedLock bit), while a TCustManager class
  65. would search for files containing external code resources of the appropriate
  66. type, create objects of class TCust to represent those resources found, and so
  67. on.
  68.  
  69. You've already dealt with some or all of these issues in your application, I'm
  70. sure.  The point that I'm trying to make is that, although the needs and
  71. services of external code resources will vary from application to application,
  72. there's an awful lot that is the same.  This similarity makes it worthwhile to
  73. have a suite of general-purpose, reuseable classes for the handling of
  74. external code resources.  This suite need not be a part of MacApp; they are a
  75. good opportunity for a third-party developer (as was offscreen drawing,
  76. yeilding OSImage), or for a Class Room project.
  77.  
  78. So — what can you tell me about Xenon's implementation of these issues?  Are
  79. you interested in working on such a suite of classes?  You certainly seem to
  80. have more experience using external code resources in MacApp than anyone else
  81. I know.
  82.  
  83. Looking forward to hearing from you again, I remain
  84.  
  85. Yours,
  86.  
  87. James Plamondon
  88.  
  89.